CIM準拠の Add-on のコンフィグを見て CIM の仕組みを知る
2024.08.26Splunk はログ分析を行うための高機能と非常に多彩なユースケースを持っていますが、Splunk Cloud などでGUIベースで設定情報を把握しようとした時に、一見すると何がどうなっているか複雑に感じるときがあります。
今回、相関分析に便利な Splunk CIM に焦点を当てて、対応している App の裏側のクエリがどういう風にログソースと紐づいて分析する仕組みになっているのかを、Add-on のコンフィグからその関連性を追ってみたいと思います。
そもそも CIM とは
Common Information Model (CIM) とは、日本語で共通情報モデルと訳せますが、IT環境において、システム、ネットワーク、アプリケーション、サービスの管理情報を典型的なオブジェクト（対象）として定義する標準
少し小難しいですが、IT環境では、様々なベンダーが独自の仕様に基づき個々のシステムを設計しているため、これらのIT環境を統合的に管理したい時に共通の仕様で対象を識別できると管理しやすくなるので、こういった標準が作られたと考えると良さそうです。
Splunk ではこの Common Information Model (CIM) の考え方を採用しており、一般的に利用されている DMTF CIM とは別に、独自に Splunk Common Information Model (CIM) というものを定義し、様々なベンダーから取り込まれるログやメトリクス情報を包括的に分析するために活用することが可能になっています。
※Splunk のドキュメント内では、Splunk Common Information Model (CIM) を CIM とだけ表現していることが多いため、このブログでも今後 CIM と表現します
この CIM を使って分析できることは、Splunk の大きな強みでもあり、相関分析を行う時に大いに活躍します。
Splunk CIM のデータモデルは以下の27種類定義されていて、こちらの公式ドキュメントで確認することもできます。
Alerts.json
Application_State.json
Authentication.json
Certificates.json
Change.json
Change_Analysis.json
Compute_Inventory.json
DLP.json
Data_Access.json
Databases.json
Email.json
Endpoint.json
Event_Signatures.json
Interprocess_Messaging.json
Intrusion_Detection.json
JVM.json
Malware.json
Network_Resolution.json
Network_Sessions.json
Network_Traffic.json
Performance.json
Splunk_Audit.json
Splunk_CIM_Validation.json
Ticket_Management.json
Updates.json
Vulnerabilities.json
Web.json
これらのデータモデルごとにイベントを紐づけ、共通の定義されたデータセットに従って、フィールドを持つことで複数の異なるシステム間で相関分析ができるようになります。
CIM と CIM対応App をインストールしてみる
CIM を使って相関分析するには、まず Splunk CIM をインストールする必要があります。
インストールは、GUIなどから簡単にインストールすることができるのでインストールします。
CIM のインストールは下準備でしかなく、その上でコンテンツを活用する必要があります。
Splunkでは、セキュリティを強化するための様々なコンテンツ（プレビルドダッシュボード、アラート、脅威ハンティングのための分析クエリなど）が提供されていますが、CIM を活用した相関分析するためのコンテンツも多く存在しています。
その中の一つとして無料で提供されている App に InfoSec というものがあります。
Splunk で相関分析しセキュリティを強化するためのスタートアップのダッシュボードとして非常におすすめな App になっています。
それでは、InfoSec をインストールしてみましょう。
InfoSec も CIM と同様にGUIなどから簡単にインストールすることができます。
適切なログが入っていない状態では、以下のように何も表示がされません。
Continious Monitoring > All Authentication のページで認証ログを分析したいと思います。
移動しますが、当然他のページも表示されていません。
ダッシュボードの内の Open in Search でダッシュボードを構成するクエリを確認します。
以下のようにクエリ文が開き datamodel=Authentication.Authentication から、Authentication データモデルを集計対象としていることが分かります。
| tstats summariesonly=true allow_old_summaries=true count from datamodel=Authentication.Authentication where Authentication.action=failure
では、この Authentication データモデルには何のログが該当して、どういったイベントが該当しているのか調べて、どのログを収集していくべきか考えていきたいと思います。
CIM準拠の Add-on のコンフィグを見て CIM の仕組みを知る
例えば、企業のFWに Cisco ASA を導入しているとして、このプロダクトから取り込んだログは CIM ではどのデータモデルに割り当てられるのかを追っていきたいと思います。
まず、ログを取り込む時に、ログのタイムスタンプの認識やフィールド抽出をする必要があります。
これを超絶簡単にしてくれるのが、Splunkbase に登録されている各種ログソースの Add-on です。
この中でもCIM準拠の Add-on とそうでないものがあり、CIMに準拠している場合、同時にCIMに準拠するような正規化をやってくれます。
Splunkbase で該当のログソースの Add-on がないかを調べて、以下の部分を見ると、CIM準拠かどうかが分かります。
Cisco ASA の Add-on はこちらになるので、CIM などと同様にGUIで簡単インストールします。
ただ今回、Web上のSplunkbaseからダウンロードして Add-on の中身を確認して、どのようにデータモデルに対応して、どのイベントがどの分析に該当するのかを調べていきたいと思います。
Zipファイルを解凍して、フォルダ構成を確認します。
% tree -d Splunk_TA_cisco-asa
Splunk_TA_cisco-asa
├── LICENSES
├── appserver
│ └── static
├── default
│ └── data
│ └── ui
│ └── views
├── lookups
├── metadata
└── static
このうち、defaultフォルダに設定ファイルが入っています。
% ls -1 Splunk_TA_cisco-asa/default/
app.conf
data
eventtypes.conf
macros.conf
props.conf
tags.conf
transforms.conf
ここで前提の知識として、以下の流れでログはデータモデルに紐づきます。
（ログ -> ログを識別 -> イベントタイプに振り分け -> タグの付与 -> データモデルへの紐づけ）
こちらのブログでもデータモデルの概念や仕組みについて紹介していますので、気になる方は確認してみてください。
最初にタグの付与に関係するコンフィグである tags.conf をエディタなどで開いて中身を見てみます。
以下のように [] がスタンザと呼ばれ、一つのコンフィグのかたまりになります。
それぞれ eventtype ごとにタグが付与されることが分かります。
また、コメントアウト部分を読むとどのデータモデルに紐づくかも記載されていることも分かります。
ログによって様々ですが、今回のように一つのログソースから色々なデータモデルに紐づくことが分かります。
[eventtype=cisco_connection]
network = enabled
communicate = enabled
#datamodels = network_traffic
[eventtype=cisco_authentication]
authentication = enabled
#datamodels = authentication
[eventtype=cisco_authentication_privileged]
authentication = enabled
privileged = enabled
#datamodels = authentication
[eventtype=cisco_vpn]
vpn = enabled
network = enabled
session = enabled
#datamodels = network_sessions
[eventtype=cisco_vpn_start]
vpn = enabled
#start = enabled
network = enabled
session = enabled
#datamodels = network_sessions
[eventtype=cisco_vpn_end]
vpn = enabled
#end = enabled
network = enabled
session = enabled
#datamodels = network_sessions
[eventtype=cisco_asa_network_sessions]
network = enabled
session = enabled
#datamodels = network_sessions
[eventtype=cisco_asa_audit_change]
change = enabled
#audit = enabled
#datamodels = change
[eventtype=cisco_asa_certificates]
certificate = enabled
#datamodels = certificates
[eventtype=cisco_intrusion]
attack = enabled
ids = enabled
#datamodels = intrusion_detection
[eventtype=cisco_asa_alert]
alert = enabled
# datamodels = alert
例として、[eventtype=cisco_authentication] のスタンザに注目してみます。
これは認証系のログだということを示していて、Authentication のデータモデルに該当します。
どのタグが付与されるかはログに付与されている特定のIDやログに含まれる特定の文字列など、ベンダー固有の何かしら意味を持つ情報を判断して、それぞれのイベントタイプに振り分けることで実現しています。
ということで eventtypes.conf を確認します。
[cisco_authentication]
search = (sourcetype="cisco:asa") (message_id="109031" OR message_id="605004" OR message_id="605005" OR message_id="716047" OR message_id="772002" OR message_id="772003" OR message_id="772004" OR message_id="113008" OR message_id="113012" OR message_id="113004" OR message_id="113005" OR message_id="611101" OR message_id="605005" OR message_id="713166" OR message_id="713167" OR message_id="713185" OR message_id="716038" OR message_id="716039" OR message_id="713198")
#tags = authentication
一例として sourcetype が "cisco:asa" かつ message_id が 109031 を持つイベントはこのイベントタイプに該当し、タグがつけられ、最終的にデータモデルにひもづきます。
message_id が 109031 のイベントはこちらの Cisco のドキュメントを確認すると、NT Domain認証の失敗ログであることが分かります。
このようにして、ログが識別され、特定のデータモデルに割り当てられることで、CIM で定義された意味のあるオブジェクト単位で相関的に検索・分析ができるようになります。
これで最初の疑問点だった、Cisco ASA は Authenticationモデル に紐づくことが分かりました。
| tstats summariesonly=true allow_old_summaries=true count from datamodel=Authentication.Authentication where Authentication.action=failure
またこのクエリ文で、where Authentication.action=failure にも注目します。
これは、Authentication データモデル内の、Authentication データセットが持っている、action というフィールドが failure のログイベントに絞り、イベント数を集計しています。
この action が failure というのは、実際の Cisco ASA のログではどんなログが該当するのか調べたいと思います。
これは、props.conf で確認することができます。
props.conf は生ログの中からフィールドを抽出する時のルールや、フィールドを別名に変えるルール、Lookupファイルを参照して値を取り出すルールを定義しています。
props.conf をエディタで開き下記の部分に注目してみます。
sourcetype を "cisco:asa" に設定した場合に、このスタンザ以下のルールが全て適用されるかたちになります。
（こちらのドキュメントの記載の通り、ログを取り込み時に sourcetype は "cisco:asa" を指定します。）
スタンザ以下の最初の5行は、タイムスタンプのフォーマット形式、タイムスタンプを識別する箇所、タイムスタンプに使われる文字数、1行を1イベントとして扱う、jsonなどのキーバリューとして自動認識するかの設定になります。
次の REPORT-xxxx の部分ですが、REPORT から始まる設定は、transforms.conf の設定を参照することになります。
（設定値が長いので省略しています。）
[cisco:asa]
TIME_FORMAT = %b %d %H:%M:%S
TIME_PREFIX = ^
MAX_TIMESTAMP_LOOKAHEAD = 30
SHOULD_LINEMERGE = false
KV_MODE = none
REPORT-cisco_asa_field_extractions = cisco_asa_log_level_message_id,cisco_asa_message_id_110003,cisco_asa_message_id_302014_302016,cisco_asa_message_id_302013_302015_inbound,...
カンマで区切られている、「cisco_asa_log_level_message_id」や「cisco_asa_message_id_110003」を transforms.conf 内で探すと、正規表現によって生ログからフィールドとして抜き出している設定を見つけることができます。
（正規表現自体の説明はここでは控えておきます。）
[cisco_asa_log_level_message_id]
REGEX = %(?:ASA|FTD)-(?<log_level>\d+)-(?<message_id>\d+)
正規表現により meesage_id というフィールドが抜き出されていることが分かります。
もう一度、props.conf に戻って、以下の設定に注目します。
LOOKUP-xxxx = yyyy zzzz OUTPUTNEW wwww の部分では、lookup ファイルと呼ばれる他のファイルを参照して、値を取り出すことを意味しています。
LOOKUP-cisco_asa_action_lookup_2 = cisco_asa_action_lookup message_id OUTPUTNEW action, action AS Cisco_ASA_action
まず最初に、yyyy 部分である cisco_asa_action_lookup となっているところだけ確認します。（transforms.conf の内容を確認する必要があるので、まずエディタで開き見に行きます。）
transforms.conf で同じスタンザを探すと以下の設定が見つかります。
これは、参照元として cisco_asa_action_lookup_520.csv を見に行くことを意味しています。
[cisco_asa_action_lookup]
filename = cisco_asa_action_lookup_520.csv
cisco_asa_action_lookup_520.csv は以下のような感じになっています。
（一部省略しています。）
vendor_action,message_id,action
aborted,,failure
accessed,,accessed
...
,111010,modified
,113008,success
,113019,blocked
...
,109031,failure
...
再び、props.conf で見ていた LOOKUP-xxxx = yyyy zzzz OUTPUTNEW wwww に話しを戻します。
イベントの message_id と、cisco_asa_action_lookup_520.csv の message_id がマッチした場合に、action のフィールドが存在していない場合に cisco_asa_action_lookup_520.csv の action を返します。
先ほどと同じ例で message_id が 109031 だった場合に、action フィールドを作って failure で返す。といった具体です。
これでまた最初の疑問に戻り、Cisco ASA のどんなイベントが分析クエリの対象になるのか分かりました。
| tstats summariesonly=true allow_old_summaries=true count from datamodel=Authentication.Authentication where Authentication.action=failure
まとめ
今回、ログイベントがどのようにデータモデルに紐づいて、CIM を使った相関分析が出来るか、Add-on の中身を見ながら調べてみました。
Splunk Cloud では基本的に中身のコンフィグ構成を気にすることがない（実際のファイルにもアクセスできない）ので、GUIベースで情報を追いがちでずが、コンフィグベースで構成や紐づけが分かっていると、Splunk を使う上で非常に役立ちそうです。
この記事がどなたかの一助になると幸いです。
